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Распределённая разработка и анализ 
функциональности компьютерной системы 
для решения задач хаотической динамики 


В статье продолжены исследования, начатые в [1] и посвященные организации процесса коллективной 
разработки компьютерной системы для решения задач хаотической динамики. Подробно описаны 
требования к функциональности компьютерной системы. Обоснован выбор архитектуры и методологии 
для дальнейшей разработки. Проанализированы средства для распределения математических вычислений. 
Подробно описан процесс разработки модуля визуализации. 


Теория хаотической динамики является современным математическим аппаратом, 
методы и алгоритмы которого существенно помогают при решении многих научно- 
технических задач математики, механики, информатики, физики, химии, экономики, 
социологии и др. Например, таких как, прогнозирование погодных условий, прогнози- 
рование поведения группы роботов и т.д. Однако существует, практическая сложность 
при исследовании динамических систем, описывающих реальные процессы, которая 
связана разработкой и реализацией компьютерно-аналитических методов. Создание уни- 
версальной компьютерной системы является важной и актуальной задачей, интересной не 
только математикам, но специалистам в области ТТ. В данной работе рассмотрены 
вопросы, посвященные организации процесса коллективной разработки компьютерной 
системы, предназначенной для решения задач хаотической динамики. 


Постановка задачи 


Целью исследования является разработка программного комплекса, применимого 
для решения определённого класса научно-технических задач, которые с математической 
точки зрения относятся к задачам хаотической динамики. Это накладывает на систему 
определённые требования. 

1. Проведение большого числа вычислительных операций. 

2. Настраиваемость под задачи пользователя (возможность решения различных задач 
класса). 

3. Возможность работы как в режиме реального времени (оп-пе), так и в режиме ой Ппе. 

С технической точки зрения система должна удовлетворять следующим крите- 
риям качества программного обеспечения: производительность, гибкость, масштабируе- 
мость, предметно-ориентированность, интероперабельность. 

С организационной точки зрения разработка данного программного комплекса 
связана с необходимостью использования методов коллективной разработки и потому 
требует разделения задач и выработки общих архитектурных решений. Это приводит 
к необходимости анализа современных технологий коллективной разработки слож- 
ных программных комплексов. 
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Система в целом состоит из набора отдельно разрабатываемых модулей, таких 
как вычислительный модуль, модуль визуализации, интерфейсный модуль и другие. 
В данной работе описывается разработка двух основных модулей системы — вычисли- 
тельного модуля и модуля визуализации. 

Основное назначение вычислительного модуля состоит в решении задач хаоти- 
ческой динамики с применением распределённых вычислительных средств. Основное 
назначение модуля визуализации — графическое представление результатов решения 
задач хаотической динамики в реальном времени. 


Выбор средств распределения вычислений 
для вычислительного модуля 


Задачи хаотической динамики отличаются значительной вычислительной слож- 
ностью, в связи с этим представляется актуальным проведение исследования способа 
распараллеливания проводимых вычислений на компьютерах, соединённых сетью. Так 
как вычислительные клиенты должны работать на соединённых сетью машинах, за ко- 
торыми работают пользователи, к ним выдвигаются следующие требования: 

— работа в системе \Мт4о\5; 

— простота установки и настройки; 

возможность отключения в ходе работы; 

незаметная для пользователя ПК работа в фоновом режиме. 

Во многих существующих публикациях о разработке параллельных программ 
обращается внимание на стандарт МРТ, который сегодня является стандартом де- 
факто для реализации параллельных вычислений в системах с распределённой 
памятью и используется во многих суперкомпьютерных задачах. Поэтому было ре- 
шено исследовать применимость именно этого стандарта. 

МР! — это программный интерфейс (АР]) и его реализация, позволяющий обмени- 
ваться сообщениями между компьютерами, выполняющими одну задачу. В настоящее 
время МРТ является наиболее распространённым стандартом интерфейса обмена дан- 
ными в параллельном программировании, существует его реализация для большого числа 
компьютерных платформ, в том числе и для Мсгозой \Мтао\. Стандарт МРГ фиксирует 
интерфейс, который должен соблюдаться как системой программирования на каждой 
вычислительной платформе, так и пользователем при создании программ, таким образом, 
МР!Г-программы являются переносимыми и для их запуска в гетерогенной сети 
достаточно провести компиляцию под каждую необходимую платформу, кроме того это 
гарантирует, что для переноса приложения с одной реализации МР! на другую необ- 
ходимо только провести пересборку, без какого-либо изменения исходного кода [2]. 

Основным средством коммуникации между процессами в МРТ является передача 
сообщений друг другу. Поддерживается блокирующая и неблокирующая пересылка 
сообщений. МР! поддерживает работу с языками программирования Еойгап, С и С++. 
Интерфейс МР]! поддерживает создание программ по принципу МИМО (Мире [1$(- 
сноп Мире Оайа). 

В качестве возможного средства реализации распределённых вычислений были 
рассмотрены доступные реализации интерфейса МР], в которых декларируется поддерж- 
ка последней версии стандарта МР1-2.0 и совместимость с \\тдо\ платформой -— это 
МРСН и У!МРИ. Для данных реализаций также декларируется поддержка работы с рас- 
пределением задач между компьютерами в сети, в том числе в гетерогенных сетях. 

С целью исследования возможности применения МРТ было разработано тесто- 
вое приложение с использованием библиотеки МРСН, реализующее параллельное 
вычисление одной из требуемых вычислительных задач. При запуске разработанного 
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теста с двумя одновременно работающими экземплярами программы на процессоре 
Репиит с технологией Нурег-ТНгеа4те скорость вычислений возросла на 62 %, что го- 
ворит об очень хорошей эффективности распараллеливания с помощью МРСН на од- 
ном компьютере. При тестировании распараллеливания вычислений между двумя 
компьютерами, соединёнными локальной сетью, скорость вычислений выросла на 93 %. 

Для библиотеки \УМР! производителем декларируется до 40 % большая произ- 
водительность по сравнению с другими реализациями МР1. Тестирование разработанного 
приложения, собранного с использованием библиотеки \/МРИ, действительно показало 
немного большую эффективность распараллеливания (2 — 3%) в сравнении с МР!СН. 
Однако в системе \У/тдо\з Ут приложения, собранные с данной библиотекой, выдают 
сообщение об устаревшей версии \У/тдо\з, при запуске же в режиме совместимости с 
МЛпдо\зХР или более ранними приложениями аварийно завершаются. К сожалению, 
эта библиотека с 2006 года не обновлялась. 

Сводная диаграмма эффективности распараллеливания с использованием раз- 
личных библиотек приведена на рис. 1. 
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Рисунок 1 — Сводная диаграмма эффективности распараллеливания построения 
огибающей поверхности 


Таким образом, единственной применимой в \У/т4до\/$ среде с бесплатной реали- 
зацией МР] является МР1СН, однако при проведении вычислений на нескольких хостах 
был обнаружен ряд её недостатков: 

— на каждом хосте необходимо наличие учётной записи пользователя с одинаковыми 
именем и паролем; 

— на каждом хосте необходимо наличие исполняемого файла, а в случае необходи- 
мости и всех необходимых файлов, к которым происходит обращение, так как МР] не 
производит копирования при запуске; 

— каждый из исполняемых файлов должен быть разблокирован в брандмауэре; 

— отсутствует встроенный механизм обнаружения разрыва связи между хостами, при 
разрыве связи возможен вход в состояние бесконечного ожидания завершения операции 
обмена сообщениями; 

— отсутствует встроенный механизм установки приоритета приложения в системе. 
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Проведённое исследование показало, что в контексте данной задачи применение 
МР! целесообразно в том случае, если вычисления будут проводиться на выделенном 
вычислительном ресурсе. В случае использования МР] на пользовательских машинах, 
развёртывание и эксплуатация системы затруднены. 


В данный момент рассматриваются следующие альтернативы: Сопдог, С1оБиз, 
Х-Сош, ОМСОВЕ. 


Особенности разработки модуля визуализации 


В процессе разработки системы компьютерного моделирования и анализа задач 
хаотической динамики возникла необходимость реализации модуля визуализации, удов- 
летворяющего следующим требованиям: быстрота визуализации большого количества 
точек траекторий, независимость от аппаратных средств, высокая детализация полу- 
чаемых изображений, настраиваемость модуля в соответствии с возможностями 
аппаратуры пользовательской платформы. 

Исходя из указанных выше требований, была поставлена цель исследования: 
разработать модуль визуализации для системы компьютерного моделирования задач 
хаотической динамики, абстрагирующий функциональность современных низкоуров- 
невых аппаратно-программных средств вывода трёхмерной геометрии и не имеющий 
от них прямых зависимостей. 

Дополнительное требование отсутствия прямых зависимостей модуля становится 
актуальным в связи с болышой сложностью современных аппаратно-программных интер- 
фейсов, таких как ОрепСТ, и ОиесХ, их высокой изменчивостью, а также несоответствием 
некоторых аппаратных средств спецификациям, предъявляемым вышеуказанными АР]. 

Рассмотрев поставленную задачу с точки зрения архитектуры программных систем, 
было принято решение разделить модуль на 3 компонента: компонент визуализации 
трёхмерных сцен, компонент визуализации трёхмерных примитивов и компонент низко- 
уровневой визуализации. Таким образом, в качестве базовой архитектуры для модуля 
была выбрана архитектура слоев. Инкапсуляция низкоуровневых особенностей визу- 
ализации трёхмерной геометрии осуществлена за счёт применения принципа инверсии 
зависимостей ОТР. Общая схема компонентов модуля приведена на рис. 2. 
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Рисунок 2 — Общая схема компонентов модуля визуализации 


Применение принципа инверсии зависимостей для организации компонентов 
позволяет решать две различные задачи независимо друг от друга. Так, особенности 
реализации модуля на ОрепСТ, не влияют на алгоритмы визуализации компонента 
Рипиуе$ гепаег, тем самым упрощая разработку модуля. Помимо этого возникает 
потенциальная возможность реализации модуля визуализации с поддержкой ОшесёХ 10 
в случае, если возможностей ОрепОТ, будет недостаточно. 

С точки зрения реализации проектного решения наиболее сложным является 
компонент Кепдег 4пуег, который должен, с одной стороны, обобщить функциональность 
современных графических АР! а с другой — предоставить возможность эффективной 
реализации вынесенной в интерфейс функциональности с учётом особенностей ап- 
паратной платформы пользователя. 
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Для решения проблемы обобщения графических АРТ было принято решение 
использовать паттерны объектно-ориентированного проектирования, в частности Абгасе 
Еасюгу и Знаезу. Совместное применение этих паттернов позволяет не только уп- 
ростить задачу, но и позволяет изменять поведение всех компонентов, входящих в 
модуль, без модификации исходного кода, что соответствует принципу ОСР разра- 
ботки программного обеспечения. 

В результате применения вышеуказанных паттернов был спроектирован интер- 
фейс компонента КепдегОпуег, диаграмма статического представления которого 
приведена на рис. 3. 
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Рисунок 3 — Диаграмма статического представления интерфейса компонента 
ВКепдегОпуег 


В процессе проектирования компонента ВепдегОпуег были выделены следую- 
щие интерфейсы: 

— ВайЙег — интерфейс работы с буферами геометрических данных (положение точек, 
их цвет, нормали); 

— Техихте — интерфейс работы с текстурами (загрузка и получение битовых образов 
различного формата); 

— Затр/ег5 же, Вепа$ае, Шер МепсИЗе — интерфейсы объектов состояния устройства 
визуализации (параметры смешивания цветов, настройки буфера отсечения и т.п.); 

— Демсе — интерфейс устройства визуализации (вывод на экран трёхмерных при- 
митивов, задание настроек визуализации). 

Основные проблемы при проектировании модуля заключались в необходи- 
мости обобщения функциональных возможностей низкоуровневых графических АР! 
с возможностью эффективной реализации, учитывающей аппаратные возможности 
компьютера пользователя. При проектировании обобщались возможности таких АР, 
как ОпесеХ 10 и ОрепОГ 2.1 - двух основных применяемых на платформе РС. При 
обобщении был выявлен ряд противоречий, среди которых — невозможность обобщить 
различия в отдельных аппаратных конфигурациях, а также сложность и громозд- 
кость обобщения отдельных мест ОрепСТ, и Ошесе Х. 
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Для решения указанных проблем были применены следующие методы проек- 
тирования. 

1. Уровневое разбиение функциональности графических АРТ и определение 
связей между уровнями. 

2. Применение паттернов объектно-ориентированного проектирования для изо- 
ляции изменчивых мест в программном коде. 

3. Выбор в качестве эталона интерфейса ОпесёХ 10 и реализация его на базе 
ОрепСТ,, что позволило постоянно согласовывать два АРТ, учитывая их особенности 
реализации, и получить проектное решение, пригодное для реализации как на базе 
ОрепОТ, так и на базе ОпесиХ. 

4. Применение метода проектирования по контракту [4], заключающегося в обя- 
зательной проверке во всех методах при реализации предусловий и инвариантов 
классов. 

Одним из основных уровней в модуле визуализации является модуль наложения 
текстур. Данный подуровень скрывает особенности реализации различных видов 
текстур, а также эмулирует отсутствие отдельных расширений ОрепОТ, для работы с 
текстурами. В частности, эмулируются расширения ОТ, АКВ {ехйхге поп ро\уег_оЁ №, 
позволяющего работать с текстурами, размеры которых не являются степенью двойки. 

Взаимодействие спроектированных интерфейсов с классами реализации на ОрепСТ, 
показано на рис. 4. 
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Рисунок 4 — Диаграмма статического представления компонента ОрепСТ.Опуег 


На диаграмме представлены три уровня. 
1. Интерфейсный уровень Го\Геуе! компонента ВепдегОпуег. 
2. Промежуточный уровень ОрепОТ..ЗВаге4, обеспечивающий взаимодействие уров- 
ней реализации компонента ОрепОТ.Опует. 
3. Уровень ОрепОГ.ТехагеМапазег, отвечающий за наложение текстур. 
Существенным при реализации уровня ОрепОГ..ТехгеМапаеег является сосре- 
доточение средств работы с текстурами в рамках одной и только одной библиотеки, а 
также замыкание создания объектов текстур в реализации класса ТехциеМапаоег.Птр|. 
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Сравнивая количество классов компонента ОрепОТ.Опуег и интерфейсного по отноше- 
нию к нему компонента Го\ТГеуе|, можно говорить о значительном снижении сложности 
при работе с компонентом по сравнению с работой непосредственно через ОрепОТ.. 

Разделение, подобное описанному выше, было произведено в рамках реализации 
всего компонента ОрепОТГ.Опуег. Это позволило выделить группы совместно моди- 
фицируемых классов и инкапсулировать их, что в свою очередь снизило общую 
сложность системы. 

Таким образом, в рамках разработки системы компьютерного моделирования и 
анализа задач хаотической динамики был спроектирован модуль визуализации. Модуль 
был разбит на три компонента, один из которых — компонент низкоуровневой визуа- 
лизации — был реализован на базе библиотеки ОрепОТ.. 

С технической точки зрения модуль содержит 75 основных классов, обеспечи- 
вающих функционирование порядка 65 функциональных точек. Общий объём кода 
модуля на С++ - 16 000 строк кода. На сегодняшний день модуль поддерживает 
ОрепОТ, версий 1.1 —2.1 и порядка 30 его расширений. Отсутствие ряда расширений 
на машине пользователя эмулируются средствами модуля. 


Выводы 


Таким образом, в рамках разработки системы компьютерного моделирования 
задач хаотической динамики были решены следующие задачи. 

1. Организация процесса разработки. 

2. Анализ инструментальных средств распределения вычислений, необходимых 
для реализации модуля визуализации. 

3. Проектирование модуля визуализации. 

4. Реализация низкоуровневой части модуля визуализации на базе библиотеки 
ОрепОГ. 
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К.А. Ручка, Л.В. Холодов, Е.Г. Мумни 

АналВ метод розподлено! розробки комп’ютерно! системи для розвязання задач хаотично! динам Жи 
У статт! запропонован1 досллдження, як! розпочати [1] та присвячен! органзаци процесу колективно! 
розробки комп’ютерно] системи для розв’язання задач хаотично! динамики. Детально описан! вимоги 
щодо функщональност! комп’ютерно! системи. Обтрунтований виб1р архтектури 1 методологИ щодо 
подалышо! розробки. Проанал!зован! засоби для розподлу математичних обчислень. Детально описаний 
процес розробки модуля в1зуал1заци. 


Статья поступила в редакцию 09.07.2008. 
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